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SUMMARY 


The NASA Lewis Research Center is developing and evaluating experimental 
hardware and software systems to help meet future needs for real-time, high- 
fidelity simulations of air-breathing propulsion systems. Specifically, the 
Real-Time Multiprocessor Simulator project focuses on the use of multiple micro- 
processors to achieve the required computing speed and accuracy at relatively 
low cost. Operating systems for such hardware configurations are generally not 
available. A real-time multiprocessor operating system (RTMPOS) that supports 
a variety of multiprocessor configurations has been developed at Lewis. With 
some modification, RTMPOS can also support various microprocessors . RTMPOS, by 
means of menus and prompts, provides the user with a versatile, user-friendly 
environment for interactively loading, running, and obtaining results from a 
multiprocessor-based simulator. This report is a users guide for RTMPOS. The 
menu functions are described and an example simulation session is included to 
demonstrate the steps required to go from the simulation loading phase to the 
execution phase. 


INTRODUCTION 

Simulations of complex dynamic systems require a versatile interface 
between the user and the simulation computer. To maximize the usefulness of 
the simulation as an engineering tool, the interface should provide a user- 
friendly means of programming, interacting with, and obtaining results from the 
simulation. In the past, different types of computers have satisfied some but 
not all of these requirements. For example, the use of analog computing equip- 
ment provides immediate results and an extremely versatile user/simulator 
interactive capability. But efficient programming and changing of the programs 
can be difficult. On the other hand, digital computers are more easily pro- 
grammed but their operating systems are generally not designed to provide the 
interactive capabilities needed for many simulation tasks. 

Simulations are becoming more sophisticated in terms of both the complexity 
of the systems being modeled and the level of model detail being sought. There 
is also a need for the simulations to execute in real time (e.g., testing of 
control algorithms and hardware-in-the-loop tests). More powerful computer 
hardware and operating systems software are needed to support these real-time 
simulation efforts. An example is the real-time multiprocessor simulator 
( RTMPS) being studied at Lewis. The objective of the RTMPS project is to 
develop and evaluate experimental hardware and software systems for the real- 
time, interactive simulation of air-breathing propulsion systems. The RTMPS 
project is focusing on the use of multiple microprocessors to achieve the 
required computing speed and accuracy at low cost relative to hybrid and main- 
frame digital computers. Although the required hardware is complex, it is 



anticipated that the desired user-friendliness can be achieved through proper 
design of the operating system. 

Grant and contract efforts related to the RTMPS project have been docu- 
mented in a number of reports. Investigations of computer architecture and 
related hardware requirements are described in reference 1. References 2 and 
3 discuss possible approaches to partitioning simulation models for solution 
on multiple microprocessors. Requirements for high-level programming languages 
for multiprocessor systems are discussed in reference 4. 

The Lewis in-house RTMPS efforts, to date, are documented in references 5 
to 9. Reference 5 describes, in general, the multiprocessor simulator concept. 
The designs of experimental hardware now in use are given in reference 6. An 
overview and users manual for a real-time multiprocessor programming language 
( RTMPL) is documented in references 7 and 8. 

A real-time multiprocessor operating system (RTMPOS) has been developed at 
Lewis to support experimental versions of the RTMPS. An overview of the design 
philosophy and features of the RTMPOS is presented in reference 9. The RTMPOS 
was designed to allow interactive, engineering-level programming and operation 
of a variety of multiprocessor configurations. To provide this flexibility, 
RTMPOS makes use of Information contained in data-base files of the type that 
are generated by the RTMPL utility (refs. 7 and 8). The RTMPOS provides 
special functions and tasks that operate in conjunction with a manufacturer- 
supplied disk operating system (DOS). Most RTMPOS tasks are written in Pascal 
and should require little or no modification to be compatible with other disk 
operating systems. The remaining tasks and routines, written in assembly lan- 
guage for the Motorola MC68000 microprocessor, provide Interfaces between 
Pascal, the DOS, and the simulator. Although these assembly programs are gen- 
erally quite simple, the extent of the modifications required to adapt them to 
other multiprocessor systems would of course depend on the particular DOS and 
type of microprocessor being used. 

This report is Intended as a guide to the use of the RTMPOS. The report 
begins with a description of the general multiprocessor architecture that is 
supported by the RTMPOS. Next, the RTMPL programming procedure is described to 
show how RTMPL output files relate to the RTMPOS. Then the general programming 
and operational functions that are provided by the RTMPOS are described. Next 
the RTMPOS menu selections are described. Finally an example of a simulation 
session is provided to illustrate the steps required to go from program loading 
to execution. 


GENERAL SIMULATOR CONFIGURATION 

The real-time multiprocessor programming language (refs. 7 to 8) and the 
real-time multiprocessor operating system (ref. 9) were developed to provide 
user-friendly programming and operation of the general simulator configuration 
shown in figure 1. The following paragraphs are Intended to familiarize the 
reader with this configuration and its associated terminology. Additional 
details can be found in references 6 to 8. 

The primary elements in this configuration are the multiple simulation 
channels (1 to n), the front-end processor (FEP), and the real-time Interface. 
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The real-time interface provides for communications between the simulator and 
external devices (e.g., strip-chart recorders and controls). The FEP serves as 
the simulator controller and the interface between the user and the simulator. 
These functions are facilitated by the RTMPOS, which resides on the FEP. Data 

are transferred between the FEP and the simulation channels via the interactive 

information bus. The RTMPOS provides for simulator run-time operations such as 
program loading, parameter changes, simulator mode control, and data handling. 
The FEP also serves the simulator peripherals (terminals, disk drives, print- 
ers, etc.). The manufacturer-supplied DOS provides such typical utilities as 
an assembler, a linkage editor, a text editor, and file-handling services. The 
resident DOS has a multitasking capability (i.e., it permits many tasks to run 
concurrently in a time-slice mode). This capability is essential to the RTMPOS 
concept since the RTMPOS includes several tasks that permit the simulator to 
send advisories to the user via the FEP while the simulation is being run. 

Each simulation channel (fig. 1) consists of two processors - a computation 

processor (COMP) and a preprocessor (PREP). Each COMP executes its assigned 
portion of the simulation (an RTMPL program) and interfaces its channel to the 
FEP. The PREP's also execute RTMPL programs and distribute information from 
the COMP's to the other channels via the real-time information bus. The COMP 
and PREP in a channel communicate through a shared memory. Each simulator 
processor contains specially designed firmware (software burned into EPROM's) 
that governs the communication between the FEP and the COMP’s and between the 
COMP's and the PREP's. The firmware performs such functions as initializing 
and checking the processor memory, transferring data, setting the execution 
mode of the processors, sending Interrupts out to the FEP, and, in some cases, 
timer control . 

One of the simulation channels (1 to n) is assigned special tasks to per- 
form. It serves as a real-time extension of the FEP and is known as the RTX 

channel. Its COMP is available to perform any real-time analysis required by 

the user to support the simulation. For example, it could be used to sample 
and process data from the other channels, which are then uploaded to the FEP by 

means of the RTMPOS. The RTX PREP is used to distribute data on the real-time 

information bus and serves as controller for that bus. It is also responsible 
for all timing and control of simulator operations. The remaining channels are 
designated as digital simulation computers (DSC's) and are available for solv- 
ing the simulation equations. 

The communication paths that are available in the general simulator config- 
uration provide a high degree of programming flexibility. As a result, the 
RTMPS can emulate a variety of multiprocessor systems. This flexibility also 
means that the RTMPOS design can be viewed as generic to a variety of multi- 
processor systems that are subsets of the general configuration shown in 
figure 1 . The only hardware constraint is that the FEP must be able to com- 
municate with the RTX COMP. 

The current Lewis RTMPS experimental hardware, the FEP, and the peripheral 
equipment are shown in figure 2. The Lewis RTMPS uses a Motorola EXORmacs 1 
development system as the FEP, and the resident DOS is Motorola's VERSAdos 1 
(ref. 10). The FEP and the simulator processors are based on the Motorola 
MC68000 microprocessor with an 8-MHz clock. 


trademark of Motorola Inc. 
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FORMULATING A SIMULATION 


Before programming a simulation for the RTMPS, a user must partition the 
simulation equations into segments that can be solved in parallel. Those seg- 
ments are assigned to the computing elements available in a particular RTMPS 
configuration. The simulation is then formulated by using the RTMPL utility 
(ref. 8). The RTMPL allows the user to program the various elements of the 
simulator in a high-level, engineering-oriented language. As shown in 
figure 3, the output of the RTMPL is a set of assembly language source program 
files (one for each processor that is being used in the simulator) and a set 
of simulation data-base files that relate the actual simulation Implementation 
to the RTMPL source programs. 

Each source program file consists of records that are given one of the 
following identifiers: VARIABLE, CONSTANT, ARGGROUP, EXEC, or TASK. The EXEC 

and TASK records for each source program define the executable parts of the 
corresponding simulation segment. The VARIABLE, CONSTANT, and ARGGROUP records 
define the local arguments for the EXEC and TASK records. A program file must 
contain at least one executive (EXEC record). Executives are like main pro- 
grams and are used to govern the computational flow of the program. Executives 
have the ability to perform tasks. TASK records are used like subroutines to 
construct a more readable and versatile program. EXEC ' s and TASK'S can have 
names up to eight characters in length. 

VARIABLE records define the time-dependent variables that appear in the 
simulation equations. In RTMPL, variables are assigned a set of attributes: 
size, data type and precision (OTP), scale factor (SF), hold value, and 
Initial-condition value (IC). The DTP and SF attributes are described in 
reference 8. Size refers to the number of current and past value terms that 
the variable has; that is, how many current and past values are to be saved in 
the simulation. The minimum variable size is 1 (i.e., only the current value 
is saved). The hold value is used to set the value of the variable during HOLO 
mode execution of the program. The IC value is the starting value of the vari- 
able that is loaded when the simulation is initialized. Hold and IC values can 
be changed at run time by means of RTMPOS commands. 

In RTMPL, constants also have OTP, SF, and size attributes. Size for a 
constant specifies the number of elements in a multivalued constant array. The 
minimum size is 1. Only constants that have been specified as parameters are 
adjustable through the RTMPOS at run time. 

An argument group (ARGGROUP) is a set of arguments that can be referred to 
by a single name. The arguments may Include constants that are local to the 
program and variables that are local or external. An external variable is a 
variable that is used in a program but whose value was computed in and trans- 
ferred from another program. Argument groups provide a convenient mechanism 
for transferring large volumes of data between the FEP and the simulator chan- 
nels. Argument groups have DTP and size attributes. For ARGGROUP's, the size 
attribute refers to the maximum number of arguments that can be contained in 
the group. Arguments may be added as long as the specified size is not 
exceeded and the argument has the same DTP as the ARGGROUP. Arguments in the 
ARGGROUP may be added, deleted, or replaced at run time through the RTMPOS. 
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The data-base files that are generated by the RTMPL are read by the RTMPOS. 
These files Include Information that the RTMPOS needs to support truly Inter- 
active execution of the simulation on the multiprocessor-based simulator. For 
example, a CONSTANT record specifies Its name, DTP, SF, size, value, and as- 
signed memory location. Reference 8 contains a sample data-base listing that 
includes the names of the data-base files as well as their contents. 

The data-base files include definitions of global constants, messages, 
operating system tasks, and general groups. Global constants have the same 
attributes as local constants but may be referenced in any program. Messages 
are advisories that are to be relayed from the simulator to the user via the 
RTMPOS under certain run-time conditions. The messages are defined by the user 
while the simulation is being programmed but may be modified at run time 
through the RTMPOS. As described in reference 8, the RTMPL utility provides 
for the definition of operating system tasks (OSTASK's) that the RTMPOS will 
perform upon initiation from the simulation. However, the current Implementa- 
tion of the RTMPOS does not support OSTASK's. That capability could be added 
as a future enhancement. A general group (GENGROUP) is very similar to an 
argument group. Two major differences are (1) that the general group cannot 
be specified through the RTMPL utility but can be specified by the user at run 
time and (2) that the general group is not tied to a specific program (i.e., it 
can include variables and constants that are computed on different processors). 
Also, there is considerably more flexibility in adding, deleting, or changing 
items in the GENGROUP. There is no restriction on item attributes (e.g., OTP's 
do not have to be the same). Like argument groups, general groups provide for 
large-volume data transfers between the FEP and simulator channels (e.g., dis- 
playing values of local variables in multiple channels). 


OPERATING SYSTEM FUNCTIONS 

All RTMPL data-base and program load-module files are saved on disk files 
that can be manipulated by the RTMPOS. Once the simulation has been formu- 
lated, the RTMPOS provides the following general programming and operational 
functions : 

(1) Simulation loading/IC and program control 

(2) Data-base management 

(3) Simulator initialization and mode control 

(4) Run-time monitoring 

(5) Simulation results management 

(6) Miscellaneous 


Simulation Loading/IC and Program Control 

The previously described source program files are assembled and linked by 
using the FEP-resident assembler and linkage editor to form program load 
modules. At run time this function allows for loading the modules into the 
simulator processors, setting the initial-condition values of simulation vari- 
ables, activating the desired EXEC in each program, and enabling/disabling 
tasks (if any) to be performed under each EXEC. 
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Data-Base Management 


Data-base management functions Include loading the data-base files Into 
the FEP memory, editing the data base, saving an edited data-base file on disk, 
and listing the data base on a terminal or printer. The editing function 
allows the user to change the simulation at run time. For example, IC and hold 
values of variables, values of local or global constant parameters, messages, 
and Items contained In arguments and general groups may be changed. The simu- 
lation programs are automatically updated to reflect the data base currently 
loaded In the FEP regardless of whether the programs are loaded Into the simu- 
lator before or after the editing Is done. Flowever, the load-module and data- 
base disk files themselves remain unchanged. The edited data base may be saved 
at any time for future use, either by overwriting the original data-base disk 
files or by saving a new set of files. Note that saving the data base does not 
affect the RTMPL source code files. Flence the changes will not appear In later 
RTMPL versions of the simulation unless changes are made In the original source 
code. 


Simulator Initialization and Mode Control 

Mode control refers to the user controlling the execution mode of the 
simulator. There are four possible modes - stop, run, hold, and cycle. When 
the simulator Is In the stop mode, execution of all simulation programs ceases. 
The simulator must generally be In the stop mode to do data-base editing. For 
example, Initial-condition or hold-condition values can be loaded only when the 
simulator Is In the stop mode. The other simulator modes ( 1 . e . , run, hold, and 
cycle) can only be entered from the stop mode. In the run mode, all simulation 
programs are executing repeated update cycles. The simulator continues to 
execute until the user Issues a stop command or the simulator or simulation 
Itself Issues a stop command. In the latter two cases, the user Is Issued an 
advisory, via the message device, that the simulation has stopped. In the hold 
mode, variables In each program are held at user-specified, fixed values. Once 
the user specifies which variables are to be held, all programs In the simula- 
tion execute a user-specified number of update cycles. The simulator then 
returns to the stop mode and an advisory Is Issued that the hold mode Is com- 
plete. At present, the cycle mode Is undefined and has not been Implemented. 

Simulator Initialization Is a hardware test that checks COMP-to-PREP com- 
munications and the shared memory within each channel. This must be done 
before the simulation program load modules can be loaded and Is usually done at 
the beginning of a simulation session. The process may have to be repeated In 
the event of a processor failure or hangup. The simulator update-interval and 
analog-to-dlgltal channel timer clocks are first set when the simulator Is 
loaded. This function provides for making subsequent changes to these clocks. 


Run-Time Monitoring 

The run-time monitoring function allows a user to receive advisories via 
Interrupts from the simulator and to record all actions that are taken during a 
simulation session. The advisories can be user or operating-system messages or 
they can be requests to read data from the simulator. The messages are dis- 
played on the user-designated message device. Current (M) and halt (H) 
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advisory messages that are generated by the operating system are listed in 
table I. The read advisories would be built into the simulation by the user 
and would be transparent to the user at run time. 


A powerful feature of run-time monitoring is the self-documenting session 
history - a disk text file that saves all user menu selections and resulting 
prompts and messages from the RTMPOS. Any advisory messages that occur are 
automatically entered into the session history, as are user-generated comments. 
The session history provides a means for correlating the session with the data 
file and can be listed and edited by using the manufacturer-suppl ied utilities 
that are resident on the FEP. Furthermore a session history can be executed by 
the RTMPOS. That is, menu selections can be input to the RTMPOS from a session 
history file rather than entered manually from the keyboard. This allows the 
user to quickly bring a simulation to a previously obtained condition by exe- 
cuting the session history from that session. The user may also create a file 
with the text editor that can be used to execute the routine parts of a simu- 
lation session (e.g., loading a data base and the simulation program load 
modules). After the execution of the session history is completed, control is 
returned to the user at the keyboard. An example session history is presented 
in a later section. 


Simulation Results Management 

The simulation results management function provides the capability of 
saving, listing, and plotting simulation results. The user can display simula- 
tor CPU time and simulation time, computation time for individual processor 
programs, and delay times, if any, for advisories and external variable trans- 
fers. The user can also display values of simulation variables as they are 
computed although this slows simulation execution time. 

Data can be saved by either of two mechanisms. The READ advisory (ref. 8) 
is built into the simulation by the user through the RTMPL. The READ advisory 
causes an interrupt that initiates an RTMPOS interrupt service task. The ser- 
vice task reads the user-specified argument group directly from the designated 
processor to an RTMPOS auxiliary storage memory. The interrupt process is 
transparent to the user. When the simulator is put in the stop mode, the data 
are automatically saved in the user-specified data disk file. These data can 
then be listed or plotted. At the present time, plotting is done outside the 
RTMPOS. 

The second and more versatile mechanism for saving data is by using the 
so-called analysis functions. These allow the user to specify general groups 
at run time that save sampled values of variables, save maximum and minimum 
values of variables, and specify the maximum allowable rate of change of the 
variables. The sampling process works in the same manner as the read advisory. 
Interrupts are issued at a sampling rate that is specified by the user. Once 
the sampling process is complete, an advisory message is issued on the message 
device. The user must then initiate saving of the data to the data file. The 
user may display the maximum or minimum values at any time. If a variable 
exceeds the maximum rate of change specified by the user, the simulation stops 
and an advisory is displayed on the message device. The particular variable 
having the rate-of -change violation is displayed on the user's terminal. 
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Miscellaneous 


Once the RTMPOS has been invoked by the user, there are two ways to exit 
from it. Using the quit option terminates all of the RTMPOS tasks permanently. 
Alternatively, the user can temporarily suspend the RTMPOS, perform other 
tasks, such as editing and listing a text file, and then resume the RTMPOS at 
the point where she/he left off. In the latter case the simulator can con- 
tinue to run with any advisory messages output to the message device as usual. 
The data read advisories are also processed. 

As a diagnostic aid, the user has the option of reading or writing memory 
locations in the simulator processors, the shared memory blocks, and the RTMPOS 
auxiliary memory block. 


INVOKING THE OPERATING SYSTEM 

Normally, the first step in invoking the RTMPOS will be to log onto the 
FEP. In the case of the Lewis system, this is done by 

(1) Turning on the system power (including the simulator) 

(2) Pressing the keyboard return key <CR> after the cursor appears on the 
monitor 

(3) Pushing the system boot button on the FEP (EXORmacs) chassis control 
and indicator panel 

(4) Pressing the break key on the terminal keyboard 

As shown in figure 4, the user will then be prompted for information. 

(Note that the user should turn on the all-caps key before making entries.) 

In the following example the user responses are underlined to distinguish them 
from system prompts: 

ENTER DEFAULT SYSTEM VOLUME: USER No. = SYS:0 <CR> 

ENTER DATE (MM/DD/YR) = 3/28/84 <CR> 

ENTER TIME (HR : M I N ) = 15:10 <CR> 

A series of messages are then displayed on the screen. The messages are 
followed by a line displaying an equal sign followed by the cursor. The user 
then enters "M POS . CF S <CR> . " This entry invokes a chain file (a series of 
commands) that results in the RTMPOS tasks being loaded from disk files into 
the FEP. If the FEP has been logged on and is in use, the user should enter 
" USE SYS : 0 & <CR>" followed by " MPOS.CF S <CR > ." 

The next user entry, " STAR <C R>." causes the RTMPOS to start executing. 

A message is displayed first showing what version of the RTMPOS has been 
accessed. (The functions provided by version 1.0, 090684, are described in 
this report. The addition or deletion of functions is indicated by a new 
version number.) The RTMPOS then goes through an initialization routine that 
attaches the simulator processor memory and the auxiliary memory to the RTMPOS 
tasks. A message is displayed to indicate whether or not the memory was suc- 
cessfully attached. The user is then prompted to designate the message device 
and a file for saving session history. The user may opt to use the default 
names. However, if the option to use the default session history file is 
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elected. It must be saved by copying It to another file at the end of the 
session or It will be lost the next time the RTMPOS Is Invoked. 

The user Is now ready to proceed with loading and execution of a simula- 
tion. The user Is prompted to press the keyboard return key <CR> to proceed 
to the main menu of RTMPOS functions or to enter a desired simulator mode 
command. The following section describes the main menu and the submenus, which 
reflect the major functions described earlier. Note that the simulator mode 
can be set by entering "S" for stop, "R" for run, "H" for hold, or "C" for 
cycle in response to any main or submenu selection prompt. 


USING THE OPERATING SYSTEM MENUS 

The RTMPOS has a main menu and five submenus. A summary of all menu 
selections for RTMPOS version 1.0, 090684, and the page they are discussed on 
is given in table II. A "<CR>" In response to a submenu selection prompt 
returns the user to the main menu. After a menu selection Is made, the RTMPOS 
will prompt the user for additional Inputs If necessary. An Illegal or Im- 
proper entry will cause either appropriate error messages to be displayed or a 
repeat of the prompt. (The appendix lists abbreviations and symbols that are 
used in the RTMPOS prompts and error messages. Not all of them are referred 
to in this report.) A general rule to remember Is that entry of "#" or any 
set of characters terminated by will cause exit from the current level of 
execution. Entry of "#" In response to more than one prompt may be required 
to exit a functional level. This is Illustrated in the section Example 
Simulation Session. 

If the required response to a menu prompt Is the name of an EXEC, TASK, 
or ARGGROUP record, the syntax of the response is as follows: 

PROGRAM. TYPE. REC0RD<CR> 

Here, PROGRAM and RECORD denote the actual program (channel) and record names, 
which can be eight characters long. TYPE denotes which processor type the 
record is associated with and Is entered as a "C" (COMP) or "P" (PREP). The 
periods are used as delimiters. The RTMPOS always provides and displays to 
the user a default program name and a default processor type. Therefore the 
program name or processor type must be entered only when it is different from 
the default. The following entries represent valid record names for EXEC, 
TASK, or ARGGROUP records: 


PROGRAM. REC0RD<CR> 

.TYPE .REC0RD<CR> 

REC0RD<CR> 

Whenever a new program or processor type is entered, it becomes the new default 
value and will be displayed by the RTMPOS. Since a GENGROUP is not associated 
with a specific simulation program, only its name, up to eight characters long, 
is entered in response to a prompt. 
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If the required response to a menu prompt is the name of a CONSTANT or 
VARIABLE record it is entered as follows: 

PROGRAM . TYPE . CONSTANTS I TEM<CR> 


or 


PROGRAM. TYPE. VARIABLES ITEM<CR> 

The syntax is similar to that described earlier except for the addition of 
another delimiter (S) and ITEM, which denotes the item number of interest in 
the particular CONSTANT or VARIABLE array. (Recall that constants and vari- 
ables have a size attribute.) The following entries represent valid record 
names for CONSTANT or VARIABLE records.: 

PROGRAM . CONSTANTS I TEM<CR> 

. TYPE .CONSTANTS I TEM<CR> 

CONST ANTS I TEM<CR> 

CONSTANTS<CR> 

CONSTANT<CR> 

The use of "SITEM" in an entry is Interpreted as wanting the specified 
item and all succeeding items in the record. The use of only "S" is inter- 
preted as wanting all items in the record. The omission of "SITEM" is inter- 
preted as wanting the first item or all items depending on the menu selection 
being used. Entry of a nonexistent item number will result in an error mes- 
sage. Although ARGGROUP's and run-time-generated GENGROUP's also have size 
attributes, they are treated as entities for most RTMPL operations. The use of 
"S" or "SITEM" with their entry is Ignored or treated as an error by the 
RTMPOS . 

Responses that Involve disk file names must be entered in accordance with 
the FEP DOS rules for naming files. In the case of the Lewis FEP, a VERSAdos 
file name consists of five parts delimited as follows: 

VOLUME: USER. CATALOG. FILE. EXTENSION 

Each part (except USER) is alphanumeric and must begin with an alphabetic 
character. "VOLUME" refers to the disk name and may be four characters long. 
"USER" refers to the user number and must be a number up to four characters 
long. "CATALOG" and "FILE" are names up to eight characters long and 
"EXTENSION" must be two characters long. Whenever a file name must be entered, 
the user is prompted for the individual parts except for the extension, which 
is always supplied by the RTMPOS. In some cases, the user is prompted only for 
"VOLUME" and "USER". 

Recall that all user entries must be followed by pressing the return key 
"<CR>" . 
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Main Menu 


The main menu of RTMPOS functions is shown in figure 4. The simulator 
mode is set by entering the first letter of the desired mode (e.g., "R" for 
run). When displayed on the user's terminal, the current simulator mode is 
indicated by an asterisk. A cycle mode has not been implemented in the current 
version of RTMPOS. The allowable simulator modes are stop, run, and hold. 

Stop mode . - "S" allows the user to put the simulation in the stop mode 
when it is in run or hold. In response to the "S" entry, the RTMPOS waits for 
notification from the simulator that it is in stop. The user is notified 
whether or not the simulator goes to stop. When a stop is executed, any user 
or operating system M and H advisories generated since the last stop are auto- 
matically saved in the session history, and read advisory data (but not sample 
data) are automatically saved in the data file. System M and H advisories are 
saved in the session history only by number. The system message numbers and 
corresponding messages are given in table I. 

Run mode . - "R" allows the user to put the simulator Into the run mode. 

In response to the "R" entry, the RTMPOS waits for notification from the simu- 
lator that it is running. The user is notified whether or not the simulator 
goes to run. The current run/hold number is displayed on the user's terminal 
and on the message device. The run/hold number is an identification number for 
transients during a simulation session. This number is used to retrieve data 
from the data file for listing and plotting. The run/hold number is displayed 
on the user's terminal and message device and entered in the session history 
each time the user puts the simulator in the run or hold mode. 

Hold mode . - "H" allows the user to put the simulator Into the hold mode. 
The hold mode must be entered from the stop mode. The user is first asked 
whether or not trie same variables are to be held again. If no previous hold 
cycles were executed or if the user wishes to change the hold variables, the 
response is "N"; otherwise the response is "Y." The user may specify the pro- 
gram variables to be held either individually or by means of argument groups 
or general groups. Specification of the hold variables by means of a general 
group is recommended as the most convenient method. Variables to be held must 
be specified by their present values. After specifying the variables to be 
held, the user is prompted for the number of update cycles to be executed in 
the hold mode. The user is notified whether or not the simulator goes to hold. 
When the proper number of cycles has been executed, the simulation is auto- 
matically placed In stop and the user Is notified, via the message device, that 
hold cycling Is complete. The user may stop the simulator before completion of 
the hold cycling by using the "S" entry. In some circumstances (such as debug- 
ging) the user may wish to have the simulation execute a specific number of up- 
date cycles. The hold mode can be used for this purpose. When the user is 
prompted for the first variable to be held, entry of "#" will result in no 
variables being held and the simulation will execute normally. The current 
run/hold number is displayed on the user's terminal and on the message device 
when the simulator goes to hold. 

Other functions, the general nature of which were described earlier, can 
be selected by entering the proper number. Entering a number between 3 and 7 
will result in the display of a submenu. 
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F unction 1, initialize simulator hardware . - The user is first prompted 
to reset the simulator processors (i.e., push the reset button on all simula- 
tor processors). A "N" entry causes return to the main menu. A "V" entry 
indicates that the reset buttons were pushed and the hardware test then pro- 
ceeds automatically. The user is notified which channels pass the hardware 
test and which channel is the RTX. If the RTX is not ready, the simulator 
cannot be used. 

Function 2, display or set update interval and number of ADC channels . - 
The current values of the update interval and the number of analog-to-digital 
converter (ADC) channels are displayed first, followed by a prompt. A "Y" 
entry indicates that the values are acceptable and causes a return to the main 
menu. If a "N" entry is made, the update-interval and ADC-interval clocks will 
be reset. The user is first prompted for the update interval in microseconds. 
The value entered must be an integer multiple of 5 with a range of values from 
100 to 81 915. The update interval is the length of time allotted to the proc- 
essors to do the simulation calculations and required data transfers. If the 
update interval and the simulation step-size parameter are equal, the simulator 
will run in real time. The user is notified whether or not the simulator will 
run in real time when the clock is set following the specification of the step- 
size parameter. 

The ADC-interval clock is set by specifying the number of analog-to- 
digital channels that are being used. The allowable number of channels will be 
governed by the length of the update interval. If too many channels are speci- 
fied, the RTMPOS notifies the user. Both clocks may be set any time after the 
hardware has been initialized. The user is always prompted to set the clocks 
when a simulation is loaded. 

Function 8. suspend RTMPOS temporarily . - The user can temporarily suspend 
operation of the RTMPOS without affecting operation of the simulator (i.e., the 
simulator will stay in its current mode). The user may then invoke any command 
recognized by the manufacturer-supplied operating system (e.g., VERSAdos). To 
resume operation of the RTMPOS, the user enters the command " MPOS.CF . 11 (When 
using the Lewis RTMPS, if the simulator is running and no user entries are 
being made to the RTMPOS, it is recommended that the RTMPOS be suspended. This 
will prevent the RTMPOS task from being aborted by VERSAdos if RTMPOS is idle 
for about 15 min.) 

Function 9. quit . - The simulation session is terminated if the current 
data base has not been edited or has been edited but previously saved. If the 
current data base has been edited but not previously saved, the user will be 
given an opportunity to save it before the session terminates. If the user 
elects to save the data base at that point, the RTMPOS will return to the main 
menu after the save process is complete, otherwise the session terminates 
automatically. 

Selection of any of the following main menu functions results in the 
corresponding submenu display. 
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Function 3, Session History 

SIMULATOR MODE (current mode displayed) 

(1) DISPLAY DATE AND TIME ON TERMINAL AND IN SESSION HISTORY FILE 

(2) ENTER A COMMENT IN SESSION HISTORY FILE 

(3) EXECUTE AN EXISTING SESSION HISTORY FILE 

(4) BE PROMPTED FOR FILE TO SAVE SESSION HISTORY 

(5) STOP SAVING SESSION HISTORY 
<CR> OR SELECTION ? .. 


The current simulator mode Is displayed at the top. Even though the simulator 
mode selections are not displayed In the submenus, the mode can be set by 
entering the first letter of the desired mode In response to the selection 
prompt, as Indicated earlier. A <CR> In response to all submenu selection 
prompts returns the user to the main menu: 


Selection 1 . - Selection 1 causes the current data and time to be dis- 
played at the terminal and entered as a comment In the session history file. 

S election 2 . - Selection 2 allows the user to enter a comment In the 
session history file (e.g., a description of the transient to be run). The 
user is prompted for the comment to be entered. A comment must be enclosed In 
asterisks, may contain any character (except an asterisk) and Is limited to 64 
characters. Two asterisks, spaced 64 characters apart, are displayed above the 
entry line as a guide to the user. An entry of "*#*" will return the RTMPOS to 
the menu. The current data and time are automatically entered In the session 
history file along with the comment. 


Selection 3 . - Selection 3 allows the user to execute the menu selections 
and responses to prompts contained In an existing session history file. The 
user is prompted for the name of the file to be executed. Session history is 
never saved during execution of the current session history file. Figure 5 
shows a listing of a typical session history file that could be executed. 
Execution of the session history file ceases when the end of the file is 
reached. The RTMPOS then returns to the menu and a message is displayed If 
session history is not being saved. Warning! Care must be taken If the ses- 
sion history file to be executed contains selections to initialize the simu- 
lator, to load a data base, or to load a simulation. If It does, the following 
respective actions should be taken before executing the session history file: 
push the processor reset buttons, delete the current data base (submenu 4, 
selection 9), and unload the simulator (submenu 5, selection 6). Otherwise 
the session history will not execute properly. There Is also a problem If the 
session history contains run (R) or hold (H) mode selections. User entries 
that are made while the simulator Is In run or hold (e.g., display of simu- 
lation values or a stop (S)) are time dependent. This time dependence is not 
accounted for during execution of the session history. That Is, each entry Is 
executed in sequence as quickly as possible. In view of the aforementioned 
problems, the user must carefully edit a session history before executing it. 
Entries in the session history that will cause Improper or unwanted actions by 
the RTMPOS can be deleted or made into unexecutable comments (to be explained 
later) . 


Selection 4 . - Selection 4 allows the user to redefine the disk file for 
saving the session history. The user is prompted for the required 
information. 
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Selection 5 . - Selection 5 allows the user to stop saving the session 
history file. After the command Is entered, no further Information Is written 
to the session history file until Item (4) of this submenu Is selected. 


Function 4, Data-Base Loading and Management 

SIMULATOR MODE (current mode displayed) 

(1) LOAD SIMULATION DATA BASE INTO FEP 

(2) DISPLAY/EDIT ARGUMENT GROUP DEFINITIONS 

(3) DISPLAY/EDIT VALUES OF SIMULATION CONSTANTS OR VARIABLE IC/HOLD 
VALUES 

(4) DISPLAY/EDIT GENERAL GROUP DEFINITIONS 

(5) DISPLAY/EDIT USER-DEFINED ADVISORY MESSAGES 

(6) SAVE CURRENT EDITED DATA BASE ON DISK(ETTE) 

(7) GET LISTING OF CURRENT DATA BASE 

(8) DISPLAY DATA BASE STATUS 

(9) DELETE CURRENT DATA BASE FROM FEP MEMORY 

<CR> OR SELECTION ? .. 

Selection 1 . - Selection 1 allows the user to load a simulation data base 
from the disk file Into FEP memory. The user Is first prompted for the name 
of the simulation definition file that Is contained In the RTMPL data base 
(catalog name SIMDEF). The RTMPOS then displays the Identifying contents of 
the file so that the user can be sure she/he has selected the right file. The 
user then has the option of loading that data base, selecting a new one, or 
quitting. Once data-base loading begins, the entire data base Is loaded Into 
FEP memory without any prompting of the user. After the data base has been 
loaded, the user may proceed with any of the data-base-management menu selec- 
tions or go on to load the simulator. The simulator Is automatically unloaded 
if It was previously loaded. 

Selection 2 . - Selection 2 allows Items to be deleted. Inserted, or sub- 
stituted for other Items In an argument group. The user Is first prompted 

ENTER ARGUMENT GROUP NAME . . 

Entry of will return the user to the menu. To modify an argument group 
named DATA, of type C, associated with program DATAPROC, the user response 
would be as follows: 

ENTER ARGUMENT GROUP NAME . . DATAPROC ,C. DATA 

or simply " DATA " If the default program and processor type are DATAPROC and C, 
respectively. The resulting prompt is 

ENTER ARGUMENT GROUP ITEM NUMBER OR NAME . . 

Here, entry of "#" returns the user to the argument group name prompt. Other- 
wise, the user must enter the name or number of the Item In the argument group 
that she/he wishes to modify. For example. If the second Item In the argument 
group DATAPROC .C . DATA Is to be changed and It happens to be the present value 
of OATAPROC.P. ANF (namely P.ANF$1), the user could enter either 11 . P. ANF$1 11 or 
"2" to modify that Item in the argument group. The following display would 
then appear: 
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DATAPROC .C .DATA$2 = DATAPROC. P.ANF$1 (XV) . . 


This prompt verifies that the second Item ($2) In the argument group 
DATAPROC .C .DATA Is the present value ($1) of ANF, from the PREP (P) processor 
for program DATAPROC, and that It Is an external variable (XV). The user then 
has the following choice of entries: 


Entry 


Meaning 


# 

<CR> 


/ 

< 

> 

New Item name 


return to the argument group name prompt 

no change to this item - display the next Item In the argument 
group (If there is one); otherwise, return to the argument 
group name prompt 

delete this item from the argument group - all subsequent items 
in the group are renumbered accordingly 
Insert a new item in the argument group before the current one 
Insert a new item in the argument group after the current one 
replace the current item with this new entry 


An entry of "<" or ">" will result in the prompt 

ENTER ARGUMENT TO BE INSERTED . . 


The user may respond with "#" or the name of the item to be Inserted. An item 
that is Inserted or used to replace the current item can be a constant, a 
variable, or an external variable that Is available to the argument group's 
program. But the new Item must have the same DTP as the argument group. An 
argument group may be added to another argument group In the same program 
provided that enough space has been allocated and that the DTP'S are the same. 
An argument group Is automatically updated In the simulator If It Is loaded 
and at the time of loading. 

Selection 3 . - Selection 3 allows values of local and global constants In 
the simulation to be displayed and values of parameters to be modified. IC and 
hold values of simulation variables may also be displayed/modified. The user 
Is first prompted 


ENTER CONSTANT OR VARIABLE NAME . . 

Entry of will return the user to the menu. An example of a valid entry Is 
ENTER CONSTANT OR VARIABLE NAME . . CORESIM.P.PRC. 

Again, CORESIM or P may be omitted If they are default values. The display 

CORESIM.P.PRC = 1.0000E+00 . . 

would Indicate that the present value of the constant Is unity. The user then 
has the following choice of entries: 
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Entry 


Meaning 


# 

<CR> 


D 

New value 


return to the CONSTANT/VARIABLE name prompt 

do not change the constant's value - display the next Item In the 
constant's array If there Is one; otherwise, return to the 
CONSTANT/VARIABLE name prompt 
replace the constant's value by the current default value 
replace the constant's value by the new value. The value may be 
entered with or without the engineering (E+00) notation 


The default option allows the user to simply enter a "D" rather than the 
entire number. The default value Is displayed whenever the user enters the 
CONSTANT/VARIABLE editing routine. Warning! Whenever a new value Is entered 
and not rejected, It automatically becomes the default value. If the default 
value Is used or a new value Is entered. It must be consistent with the 
constant's DTP. An Illegal value will be rejected with an error message and 
the user will be prompted again. In some Instances the user may also receive 
a warning (e.g., when a decimal value Is entered for a constant Integer). In 
this case the value Is not rejected unless It Is out of range. In which case 
an error message would be given. In the event that the user modifies a global 
constant. It Is automatically updated everywhere that the global constant Is 
used In the simulation. 


The procedure for displaying/modifying variable IC and hold values Is 
essentially the same as that described for the constants. When a variable name 
Is entered, the IC value will be displayed first regardless of selection 
number. The user will then have the same choice of entries as for a constant. 
Any entry other than results In the hold value then being displayed with 
the same entry options. Warning! While the RTMPOS does allow present 
(ITEM = 1) and past (ITEM > 1) values of variable IC's to be different (l.e., 
simulation starting from a nonequilibrium condition), the firmware currently 
Implemented results In all past values being set equal to the current value 
when the simulation IC's are set. Hence a simulation will start from a non- 
equilibrium condition only when a run (R), stop (S), run (R) sequence of mode 
changes Is used. 

Selection 4 . - Selection 4 allows the user to build or edit a general 
group at run time. The Initial prompt Is 

ENTER GENERAL GROUP NAME . . 

Entry of "#" will return the user to the menu. Otherwise, the user must enter 
a name up to eight characters long - the first being alphabetic. No program 
name or processor type Is attached to a general group. If the name entered by 
the user does not exist, the user Is notified and a new general group by that 
name can be created. Processing of a general group and the choice of entries 
In response to prompts is the same as that for an argument group. Any con- 
stant, local variable, argument group, or general group may be added to a 
general group. When the user specifies an argument or general group to be 
added, the RTMPOS adds It Item by Item rather than as an entity. If an argu- 
ment group contains an external variable. It Is entered In the general group 
as coming from the source processor. There Is no restriction on DTP or size. 
Once the general group Is formed, It may be saved on a disk as part of the 
data base. 
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Selection 5 . - Selection 5 allows the user to modify the user-defined M 
and H advisory messages that are sent to the user from the simulator via the 
FEP. The user Is first prompted 


ENTER MESSAGE NAME . . 

Entry of "#" returns the user to the menu. Message names are alphanumeric, up 
to eight characters long, and are not specific to any program. For example, 
if the user wanted to modify a previously defined message named DUCTMESS, the 
entry would be 


ENTER MESSAGE NAME . . DUCTMESS 

The specified message would then be displayed followed by the prompt 

OK ( Y/N) ? . . 

A "Y" response would Indicate that the message was all right - no change 
desired. The message name prompt would then be displayed again. A "N" re- 
sponse would mean the user wished to change the message. A message must be 
enclosed In asterisks, may contain any character (except an asterisk), and may 
be 64 characters long. Two asterisks spaced 64 characters apart are displayed 
above the entry line as a guide. An entry of "*#*" will return the RTMPOS to 
the menu. 

Selection 6 . - Selection 6 allows the user to save an edited simulation 
data base to disk files. If the data base has been loaded from a disk and has 
not been edited, the RTMPOS will not permit that data base to be resaved to a 
disk. However, the manufacturer-supplied copy utility may be used to save such 
files under a different name. If the RTMPOS determines that the data base has 
been edited and can be saved, the user Is given the option of either over- 
writing the files from which the current data base was loaded or generating a 
completely new set of files. If the latter option Is elected and there Is suf- 
ficient room on the disk. It Is recommended that different data bases for the 
same simulation be saved under different user numbers. 

Selection 7 . - Selection 7 allows the user to obtain a listing of the sim- 
ulation data base currently residing In the FEP memory. Because the data base 
Is not a text file, it cannot be obtained by using the manufacturer-supplied 
list utility. The user may elect to list all or part of the data base. 

Selection 8 . - Selection 8 allows the user to determine what data-base 
files have been edited. After the command Is entered, either a message will be 
displayed Indicating that the current data base has been saved or a prompt will 
be displayed asking if the user wants to display the names of the data-base 
files that have been edited. 

Selection 9 . - Selection 9 allows the user to free FEP memory by deleting 
the current data base. Only one data base at a time is allowed to reside In 
the FEP memory. 
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function 5, Simulation Loadlng/IC and Program Control 

SIMULATOR MODE (current mode displayed) 

(1) LOAD SIMULATION INTO SIMULATOR 

(2) SET SIMULATION IC'S 

(3) CHANGE BACKGROUND EXECUTIVES 

(4) ENABLE/DISABLE PROGRAM TASKS 

(5) DISPLAY PROGRAM STATUS (ACTIVE EXECUTIVES AND ENABLED TASKS) 

(6) UNLOAD SIMULATOR 

<CR> OR SELECTION? . . 

Selection 1 . - Selection 1 Initiates loading of simulation programs. A 
data base must reside In the FEP before this selection can be made. The user 
Is prompted to select a channel for each simulation program that Is specified 
In the simulation. If the configuration Is DUAL, associated (same program 
name) COMP and PREP programs are automatically put Into the same channel. The 
specified processor function (RTX or DSC) for each program must be compatible 
with the assigned channel or the assignment will not be made and an error mes- 
sage will be displayed. (When the simulator hardware Is Initialized, the RTX 
channel number Is displayed.) Every program must have a channel assignment or 
an error will occur. Once the assignments have been made, the user Is given 
the option to load or not to load. After the simulator Is loaded, the RTMPOS 
automatically (1) updates each program's CONSTANT and ARGGROUP records to be 
consistent with the data base currently residing In FEP memory, (2) Initializes 
variables, (3) enables/dlsables tasks, according to conditions originally set 
through the RTMPL utility, (4) activates the first zero priority background 
executive specified In each program, and (5) displays the simulation status 
showing the active executive and enabled tasks In each program. The user Is 
prompted to enter the name of the Integration step-size parameter, to set the 
update-interval and number of ADC channels, and to name the file for saving 
simulation results (data). The Integration parameter should be specified as a 
global parameter when the simulation Is being developed with the RTMPL utility. 
This makes It easier to modify at run time and to coordinate with the simulator 
update Interval by means of the RTMPOS. 

Selection 2 . - Selection 2 allows the user to set the IC values of program 
variables In the simulator. The simulator must be In the stop mode. The user 
may specify the variables to be Initialized either Individually or by means of 
argument groups or general groups. There Is also an option to set the IC 
values of all simulation variables without having to enter them Individually 
or by means of a group. If not all variables are to be Initialized, use of a 
general group Is recommended as the most convenient method to specify IC's. 
Variables to be Initialized must be specified by their present value. When 
variables are Initialized, they automatically have their past values set equal 
to the present value by means of the simulator firmware. Whenever the simula- 
tion IC's are set, the run/hold number counter Is Incremented. 

Selection 3 . - Selection 3 allows the user to activate a specific zero 
priority executive In a selected simulation program file. Any other zero pri- 
ority executives In the same program are automatically deactivated. The user 
Is given the option of (1) entering the name of the executive to be activated 
or (2) reviewing the status of all executives with the opportunity to change 
the status of each. As stated earlier, eight characters may be entered for an 
executive name (plus program and processor type). However, only the first 
seven characters are recognized (ref. 8). Note that, when the simulation 
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programs are first loaded, the RTMPOS automatically activates the first zero 
priority executive specified In each simulation program. 


Selection 4 . - Selection 4 allows the user to enable or disable any simu- 
lation task - no other task Is affected. The user Is given the option of (1) 
entering the name of the task to be enabled/dl sabled or (2) reviewing the sta- 
tus of all tasks with the opportunity to change the status of each. As with 
executives, eight characters may be entered for a task name, but only the first 
seven characters are recognized. Note that, when the simulation programs are 
first loaded, each task Is enabled or disabled according to the status Ini- 
tialized by the user through the RTMPL utility. 

Selection 5 . - Selection 5 causes the simulation status to be displayed, 
showing the active executive and enabled tasks In each simulation program. An 
example Is shown In the session history file listing of figure 5 (lines 64 to 
69) . 


Selection 6 . - Selection 6 sets In the RTMPOS a Boolean parameter Indicat- 
ing that the simulator Is not loaded. This selection must be used If simula- 
tion programs have previously been loaded and the user wishes to execute a 
session history file that contains a selection to load the simulator. Other- 
wise the session history file will not execute properly. 


Function 6, Simulation Results Management 
The selections In submenu 6 are 

(1) ACTIVATE/DEACTIVATE ANALYSIS FUNCTIONS 

(2) SAVE SAMPLE DATA, DISPLAY MAX/MIN VALUES 

(3) DISPLAY SIMULATOR CPU TIME AND SIMULATION TIME 

(4) DISPLAY COMP AND PREP COMPUTATION TIMES 

(5) BE PROMPTED FOR FILE TO SAVE SIMULATION RESULTS 

(6) LIST SIMULATION RESULTS DATA FILE 

(7) PLOT SIMULATION RESULTS DATA FILE 

(8) DISPLAY SIMULATION VALUES OF CONSTANTS, VARIABLES, AND ARGUMENT/ 
GENERAL GROUPS 

(9) DISPLAY COMP AND PREP ADVISORY MAX-DELAY TIMES 

(10) DISPLAY EXTERNAL VARIABLE DELAY TIMES 

<CR> OR SELECTION? . . 

Selection 1 . - Selection 1 allows the user to activate or deactivate any 
of the four analysis functions: (1) sample values of variables, (2) save maxi- 

mum values of variables, (3) save minimum values of variables, and (4) set max- 
imum allowable rate of change of variables. The user Is first prompted to 
select the desired analysis function or to quit. If the selected function Is 
already activated, the user Is so notified and given the option to abort It. 
Otherwise the user Is prompted for the name of the general group containing the 
variables to be processed by the selected analysis function. The general group 
must already exist or an error message will occur. Each analysis function can 
process 16 variables. If the selected general group contains more than 16 
Items, only the first 16, whether constants or variables, will be used and a 
warning will be Issued. All scaled fraction values are truncated to single 
precision and only single-precision Integers are allowed. After setting up an 
analysis function, the user Is prompted for another selection until the quit 
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option is selected. Except for the sampling process, analysis functions can 
only be aborted or deactivated by this submenu selection. The analysis func- 
tions can be set up with the simulator in any mode. 

The sample process allows data to be read from any simulator processor and 
saved by using the same interrupt procedure that is used by the RTMPL read 
advisories (ref. 8). When the sample process is active, read advisories are 
ignored and tasks containing read advisories should be disabled so that unne- 
cessary interrupts are not issued. The user can elect to have the sample proc- 
ess trigger as soon as the simulator is put in the run or hold mode or when 
the value of a variable in the general group reaches a specified level. In 
the latter case the user is prompted for the variable to be used, the trigger 
level, and an absolute-value bandwidth about the trigger level. The sample 
process then triggers if the value of the variable comes within the trigger 
level, plus or minus the bandwidth. If the run/hold trigger option is se- 
lected, the sample will begin after the user quits the analysis functions setup 
routine and the simulator is placed in run or hold. The user is also prompted 
for the number of update intervals between samples and the number of samples 
desired. The RTMPOS displays the maximum number of samples allowed based on 
the memory size allotted to saving data. When the sample process is complete, 
an advisory is issued on the message device. Processing of the data is dis- 
cussed in item 2 of this submenu. 

The max/min value functions keep track of the maximum and minimum values 
of variables in the general group selected for each function. The same general 
group could be used for both functions. The max/min values are initialized to 
the values of the variables at the time that the function is activated. When- 
ever the variable IC values are set (main menu function 5, submenu selection 
2), the max/min values are also initialized to the IC values if the max/min 
functions are active. 

The maximum rate-of-change function allows the user to specify the maximum 
allowable change of variables per update interval (or time step). If the allow- 
able change is exceeded, the simulator goes to the stop mode and a message 
advisory is displayed on the message device. The next entry by the user will 
result in a display on the user's terminal indicating which variable caused the 
rate-of-change violation. 

Selection 2 . - Selection 2 allows the user to save sample data or to dis- 
play maximum or minimum values resulting from the corresponding analysis func- 
tions. The user is prompted to select the desired function or quit. An 
asterisk indicates which of the functions are active. Unlike the read advisory 
data, saving the sample data to the data disk file must be initiated by the 
user. If the user attempts to save the sample data before the sample is com- 
pleted, the user is notified and given the opportunity to terminate the sample. 
The user then has the option of saving the partial sample. The sample data are 
saved in the data file that was previously specified by the user. The user can 
also elect to display the maximum or minimum values if those functions are 
active. The results are displayed on the user's terminal and saved in the ses- 
sion history file. 

Selection 3 . - Selection 3 allows the user to display the number of update 
intervals, the simulator CPU time (update-interval clock times the number of 
update intervals) and simulation time (integration step-size parameter times 
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the number of update Intervals) since the last simulation IC. These values can 
be displayed with the simulator In any mode. 

Selection 4 . - Selection 4 allows the user to display the time required to 
calculate the program residing on each simulator processor. The values can be 
displayed with the simulator In any mode. 

Selection 5 . - Selection 5 allows the user to redefine the disk file for 
saving simulation results. The user Is prompted for the required Information. 
The user Is automatically prompted for this file when a simulation Is first 
loaded. 

Selection 6 . - Selection 6 allows the user to obtain a listing of simula- 
tion results, in engineering units, that have previously been saved In a data 
disk file as a result of the read (R) advisory (ref. 8) or the analysis sample 
function. The user Is prompted for the list device (e.g., a printer or the 
user's terminal) and the data file to be listed. The user can then elect to 
list results of a specific run/hold number or the entire file. 

Selection 7 . - Selection 7 allows the user to obtain plots of data that 
have previously been saved In a data disk file as a result of the read (R) 
advisory (ref. 8) or the analysis sample function. Warning! This function Is 
not currently Implemented In the RTMPOS. Therefore plotting must be done by 
means of a separate program. The user Is prompted for the required 
information. 

Selection 8 . - Selection 8 allows the user to display current values of 
simulation constants and variables (local or external). All values are re- 
trieved from the proper simulator processor except for nonparameter constants 
that are assigned as immediate data by the RTMPL. Immediate data values are 
retrieved from the data base and are preceded by the expression IMMED.DATA:. 

The user specifies an external variable by preceding the name with For 

example, suppose It Is desired to display the value of the external variable 
DATAPROC . P.ANF$1 that Is used In program DATAPROC.C. First of all, DATAPROC.C 
must be the default program and processor type. The user then enters 
@DATAPR0C.P.ANF$1 or simply .P.ANF$1 since DATAPROC Is the default program. 

The value displayed is the most recent value of ANF$1 transferred from the 
PREP to the COMP and Is retrieved from the COMP. An entry without (l.e., 
DATAPROC. P. ANF $1 ) results In the value of ANF$1 being retrieved from the PREP. 
The user Is prompted for the Item to be displayed. The name of a constant, 
variable, argument group, or general group may be entered. All Items of a 
constant or variable array will be displayed, beginning with the first one 
specified, until the user exits the array by entering The user cannot 

change values by means of this function. The function can be used In any sim- 
ulator mode. Values displayed on the user's terminal are also saved in the 
session history. Note that displaying values with the simulator In the run 
mode will slow down the simulator. 

Selection 9 . - Selection 9 allows the user to display the maximum delay 
times of message and read advisories from all simulator processors. The delays 
for all channels are displayed automatically at the user terminal and written 
Into the session history. 
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Selection 10 . - Selection 10 allows the user to display the transfer delay 
times of external variables. The user is given the opportunity to display 
delay times for each program that contains external variables. 


Function 7, Read/Write Memory Location 

SIMULATOR MODE (current mode displayed) 

(1) DISPLAY MEMORY LOCATION 

(2) WRITE MEMORY LOCATION 

<CR> OR SELECTION? . . 

Selection 1 . - Selection 1 allows the user to display the contents of sim- 
ulator and RTMPOS auxiliary memory locations. The simulator memory includes 
the COMP, the PREP, and the shared memory. The user first selects the type of 
memory to be read and then the channel number (except for auxiliary memory). 

The user is then prompted for the desired offset address where a zero offset 
represents the first byte of the memory being addressed. The offset can be 
entered in decimal or hexadecimal format. Hexadecimal values must be preceded 
by two apostrophes. Offsets that are not entered as an even number are auto- 
matically rounded down to the nearest even address. Eight bytes are displayed 
at a time and the values are given in hexadecimal. The user then has the op- 
tion of entering a new offset, pressing the return key <CR> for the next eight 
bytes, or entering "#" to return to the menu to select another memory or quit. 

Selection 2 . - Selection 2 allows the user to write to simulator and 
RTMPOS auxiliary memory. In this case simulator memory includes only the COMP 
and PREP. Warning! The user should obviously be knowledgeable about the 
memory locations being written to, so as not to affect simulator operation or 
simulation execution. The user is prompted for the type of memory, the channel 
number, and the offset address. When writing to the auxiliary memory or COMP 
memory, only one byte is written at a time and the address can be even or odd. 
When the PREP is selected, two bytes must be written and the offset must be 
even. 


DISK FILE MANAGEMENT 

The RTMPOS can generate files that contain the following types of 
information: 

( 1 ) An edited data base 

(2) Session history 

(3) Simulation results 

As explained earlier, the data-base files are an output of the RTMPL utility. 
The user can then edit those files by means of the RTMPOS and save the new 
files. Since these files may be large and there may be many of them, the user 
will probably want to copy these files to another disk and delete them from the 
operational disk. This procedure is recommended because the RTMPOS will crash 
if there is an attempt to overfill the operational disk. 

File types 2 and 3 have default names defined by the RTMPOS. The user has 
the option of redefining those names. The session history and simulation 
results files will, in general, contain important information about a given 
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simulation session. It Is recommended that they be redefined at the beginning 
of each session or that the default files be saved at the end of each session 
by copying them to another file or disk. 

Files may be copied or deleted from a disk by using the appropriate 
manufacturer-supplied operating-system command on the FEP. For the NASA Lewis 
FEP the commands are COPY or OEL followed by the file name and desired options. 
The user should refer to the manufacturer-supplied FEP users manual for the 
exact form of the copy and delete commands . 


EXAMPLE SIMULATION SESSION 


The example presented here Is Intended only to Illustrate the sequence 
required to get a simulation up and running. It does not Illustrate the full 
capabilities of the RTMPOS. The example simulation Is based on a typical 
small-turboshaft engine. A single-channel, dual-processor simulation was deve- 
loped by using the RTMPL utility. The simulation equations were allocated to 
the COMP and PREP processors so as to minimize execution time for the two- 
processor configuration. Details of the partitioning are not presented herein. 


The process of building the simulation by using the RTMPL utility Is de- 
scribed In reference 8. The outputs of the RTMPL utility are simulation data- 
base files and assembly language source files for each simulation program. The 
program source files are listed as part of the data-base listing. For this 
simulation the source files are DEVI :0.0BJC0MP.T700DUAL.SA and DEVI -.O.OBJPREP. 
T700DUAL . SA for the COMP and PREP, respectively. Before the simulation can be 
loaded and executed, the source files must be transformed Into executable 
machine code for the target processors. In general, this Is done by using a 
manufacturer-supplied assembler and linkage editor that are resident on the 
FEP. Once the user has logged on, as described earlier, the assembler and 
linkage editor are Invoked. The following commands assemble and link the 
source file for the COMP processor on the NASA Lewis RTMPOS: 


= ASM DEVI :0.QBJCQMP.T700DUAL.SA 


= LINK DEVI :0. QBJC0MP.T700DUAL.ro 


Both of the program source files must be assembled and linked In this way. The 
user should refer to the documentation for the manufacturer-supplied assembler 
and linkage editor for descriptions of the exact syntax to be used and possible 
options that are available. The example presented herein assumes that the sim- 
ulation has been formulated by using the RTMPL utility and that the program 
source files have been assembled and linked. 

Figure 4 shows the terminal display for beginning the example simulation 
session. An "=" generally Indicates a prompt from the manufacturer-supplied 
DOS. Various displays followed by ". ." Indicate a prompt from the RTMPOS. In 
all cases the user types her/his response and then enters it by pressing the 
keyboard return key <CR>. The following commentary explains the session as It 
progresses . 

The first step Is to Invoke the RTMPOS as described earlier. Lines 1 to 4 
show the log-on process; the blank lines (5 to 7) represent a series of log-on 
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messages from VERSAdos. The RTMPOS Is then started by the chain file command 
"MPOS.Cf S" (line 8). The chain file commands (lines 9 to 19) are then dis- 
played. The RTMPOS Is Initiated by the STAR(t) command (line 21). The default 
message device Is Indicated to be the line printer designated as "#PR." The 
user accepts that by typing "Y" on line 30. The prompt on line 32 means that 
the user should be sure that the printer Is turned on and properly configured 
to receive messages before pressing the return key. 

Lines 34 to 49 define the session history file. The user elects not to 
use the default file name by typing "N" on line 34. The user Is then prompted 
for the parts of the file definition. Session history file extension Is always 
"SH." The user must be sure that the designated volume (disk) Is loaded and 
the RTMPOS then tests If the file already exists. If It does, the user can 
overwrite the existing file or enter a new name. The session history name Is 
displayed on the user's terminal and on the message device (fig. 6). The 
RTMPOS Is now Initialized and the user Is ready to begin the simulation ses- 
sion. The message on lines 52 to 53 (fig. 4) Indicates that the user can 
change the simulator mode In response to any main menu or submenu prompt. 
Pressing the return key (line 54) results In a main menu display and prompt 
(lines 60 to 79). The asterisk on line 63 Indicates that the simulator Is 
currently In the stop mode. 

The remainder of the example session will be explained with the aid of the 
session history file that was generated during the example session. A listing 
of the session history Is given In figure 5. All lines beginning with an 
exclamation point (e.g., line 1) are treated as unexecutable comments. These 
Include all nonuser entries such as prompts and other terminal displays and 
messages. The exclamation point Is a signal to prevent the RTMPOS from trying 
to execute that entry when a session history file Is being executed. A user 
can therefore make an executable session-history entry Into an unexecutable 
comment by Inserting an exclamation point at the beginning of the proper line. 
This would be accomplished by means of the manufacturer-supplied text editor 
utility. Whenever a prompt Is Included In the file, the user's response Is 
given on the next line (e.g., lines 5 and 6). A blank line Indicates a car- 
riage return <CR> response to a prompt (e.g., line 11). RTMPOS prompts that 
are repeated often or are not necessary for understanding the session file are 
omitted from the file to save space. Some user responses are entered In the 
session file only as a comment. These Include main menu selection 8 and 
session-history-menu selections 3 to 5, which would cause problems If they were 
to be executed as part of the session history file. When an Improper response 
Is entered by the user, "IERR0R!" Is written Into the session file, but the 
entire error message Is not written. 

A typical user procedure after the RTMPOS Is Invoked would be the 
following: 

(1) Initialize the simulator hardware. 

(2) Load the data base for the desired simulation. 

(3) Edit the data base If required. 

(4) Load the simulation programs. 

(5) Set up the desired analysis functions. 

(6) Run the simulation and obtain results. 
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To Initialize the simulator hardware the user enters main menu selection (l.e., 
function) 1 (fig. 5, line 6). (All subsequent line numbers refer to the ses- 
sion history.) The user Is prompted to reset the simulator processors (l.e., 
push the reset buttons on the processor boards). A response of "Y" (line 7) 
Indicates that this was done and the hardware test proceeds. (A response of 
"N" would have aborted the hardware Initialization and returned the user to the 
main menu.) Lines 8 to 10 Indicate successful completion of the hardware test 
and that the RTX Is channel 1. The fact that the advisory link Is operational 
between channel 1 processors and the FEP Is displayed on the message device 
(fig. 6). During this session, only one channel was available. When multiple 
channels are available, the status of each channel and the RTX channel number 
Is displayed. The <CR> entry (line 11) returns the user to the main menu, and 
selection 4 Is made to do data-base-related functions. Data-base submenu 
selection 1 allows a data base to be loaded. The user Is prompted for the 
parts of the simulation definition file, with responses on lines 16 to 19. The 
RTMPL catalog name for this file Is always SIMDEF. (The user can change the 
name by means of VERSAdos utilities.) The file name T700DUAL Is the same as 
the RTMPL user-selected simulation Identification name. The RTMPOS tests for 
the existence of the file, displays identifying Information from the file on 
the user's terminal, and gives the user the option to load It or not. 


Once the data base Is loaded (lines 21 and 22), the user can make other 
submenu selections to edit It. In this session the user selects 4 to edit the 
general group, 6R0UP1 . The group does not exist, so It Is created (lines 27 
and 28). Although It Is not shown In the session history, the default program 
Is the COMP. Therefore TIME and NP come from the COMP program. TIME Is a 
running measure of simulation time In seconds, and NP Is the power turbine 
speed In revolutions per minute. The Item .P.NG Is the compressor speed In 
revolutions per minute, and the .P. indicates that It Is located In the PREP. 
Because the COMP and PREP programs In the same channel have the same name, 
T7002CH1 in this case, it is not required as part of the entry, 
now the default processor until the user enters a prefix of .C. 

The user then escapes from the general group editing routine by 
(lines 37 and 39) In response to two successive prompts. 


The PREP Is 
to change It. 
entering "#" 


The user next proceeds to load the simulator (main menu function 5, sub- 
menu selection 1). The user Is prompted for the channel In which to load pro- 
gram T7002CH1 , which Is Indicated to be an RTX program (line 47). Channel 1 
must be selected (line 48) because It has been Identified as the RTX (line 10). 
If there had been multiple DSC programs In the simulation, any ready DSC chan- 
nel could have been chosen for any DSC program. Lines 52 and 53 Indicate that 
the simulation programs have been loaded. The user Is then prompted (lines 54 
and 55) for the name of the simulation Integration step-size parameter (assumed 
to have units of seconds) so that the RTMPOS can coordinate It with the simula- 
tor update Interval prompted for on line 57. After the display of the current 
value of the step size (line 56), lines 57 and 58 display the default values of 
the update Interval (5000 us) and the number of ADC's (zero since analog-to- 
digital convertors are not currently Implemented). The "Y" response on line 60 
Indicates that the default values are acceptable. An entry of "N" would have 
allowed the user to change those values. Lines 61 to 69 Indicate that the sim- 
ulator will run slower than real time and that the simulation Is loaded and 
updated for the current data base and give the status of simulation executives 
and tasks. The user then selects the default data file by entering "Y" (line 
70) to the name that Is given on line 71. An entry of "N" would have allowed 
the user to rename the data file. The simulator automatically executes one 
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hold cycle to initialize simulation external variables and then returns to the 
stop mode. Execution of the stop mode causes previously generated advisory 
messages to be entered into the session history. Lines 75 and 76 are the 
advisory link operational messages previously seen on the message device 

(fig. 6). 

Before running the simulation, the user may wish to set up an analysis 
function to obtain data. The set up is done on lines 81 to 93. This partic- 
ular sequence is for setting up the sample process by using GR0UP1 , which was 
formed previously in the session. The user elects to trigger on run/hold mode 
(lines 87 and 88) rather than selecting a trigger variable. The user then 
enters the number of simulator update intervals per sample (line 90) and the 

number of samples desired (line 92). (The maximum number of samples allowed is 

displayed on the user's terminal but not in the session history.) The user 
exits the analysis function setup procedure by entering "Q" (line 93) and sub- 
sequently puts the simulator into the run mode (line 96). Note that the mode 

change takes place in response to a submenu prompt. When the sample process is 

complete, an advisory is displayed on the message device (fig. 6) and the user 
puts the simulator in stop (line 101). The sample process complete message is 
then entered in the session history (line 102). The user saves the sample data 
to the data file (lines 105 to 107) and a message is displayed (line 108) that 
20 records of data were obtained as specified on line 92. The user then 
returns to the main menu and quits the simulation session (line 114). 

Since the data base had been modified by creating a general group, the 
user is now advised that the edited data base has not been saved (line 115). 

The user selects the option to save the data base before quitting, to display 
the names of the data-base files that were edited, and to overwrite the exist- 
ing data-base files. Only the simulation definition file and the modified 
files are overwritten, and in this case the modified files are actually new 
because there were no general groups previously. After the data base is saved, 
the RTMPOS returns to the main menu prompt (line 133). The user then termi- 
nates the session by entering "9" (line 134). 

The user could create the same or any session history file by using the 
manufacturer-supplied text editor. For example, the user could create a 
standard text file that, with only minor editing, would allow loading of any 
simulation data base and the simulator without manual entry of all of the menu 
selections and prompt responses. However, care must be taken to include a 
response for all prompts that will occur. The prompts that occur will often 
depend on the responses to previous prompts. For example, in figure 5, re- 
sponses (lines 16 to 19) to the prompts that occur after the load data-base 
selection (line 15) will depend on whether or not a session history file was 
previously loaded. The session history of figure 5 could, for example, be 
modified to load any single-channel, dual -processor simulation by editing the 
parts of the file definition (lines 16 to 19 and lines 50 and 51) and any other 
items (e.g., integration step-size parameter, line 55) that would be different. 
Lines 80 to 134 of the file, as well as any comment lines, could be deleted to 
simply bring the simulation to a loaded and ready-to-run condition. The re- 
sultant file would be like the one shown in figure 7. 
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CONCLUDING REMARKS 


An operating system (RTMPOS) that provides versatile and user-friendly 
means for Interactively programming, running, and obtaining results from a 
real-time multiprocessor simulator has been developed. The RTMPOS acts in con- 
cert with a manufacturer-supplied disk operating system that provides the usual 
operating system functions such as assembling, linking, text editing, and file 
handling services. The RTMPOS facilitates the running of simulations that have 
been formulated by using a real-time multiprocessor programming language 
( RTMPL) utility. The RTMPOS menus provide for run-time operations such as 
loading, modifying, and specifying computational flow of programs, simulator 
mode control, data handling, and run-time monitoring. Run-time monitoring is a 
powerful feature that provides the user with a self-documenting history of the 
simulation session. The user may then use that history at a later date to 
automatically recreate the session. The session history also coordinates the 
session with the data file. 

The capabilities that were described represent the first edition of the 
RTMPOS. Future enhancements to the operating system are expected to Include 
the following capabilities: 

(1) Simulation static test 

(2) Enhanced analysis and graphical display of simulation results 

(3) More extensive simulator hardware status checks 

(4) Handling of simulator advisories that will allow for such things as 
initiation of a user-generated operating-system task 

Since the RTMPOS is an outgrowth of a research effort, the implementation of 
these improvements will depend on the results of further applications and the 
users' acceptances and responses. The present NASA Lewis application of the 
RTMPS is to the simulation of air-breathing engines to facilitate the study of 
engine dynamics and control systems. However, the RTMPS has potential for much 
wider applications and should be beneficial to any simulation or process that 
would benefit from parallel processing. For example, the RTMPOS itself could 
serve as the interface between a facility, such as a wind tunnel, and the oper- 
ator. The RTMPOS would provide the means for the operator to make changes to 
and monitor facility operating conditions, while the simulator could act as the 
facility control system and be Interfaced to the facility sensors, actuators, 
etc . 
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APPENDIX - SYMBOLS AND ABBREVIATIONS 


ADC 

AO A7 

C 

CHAR 

CHG 

CN 

D 

DB 

DEL 

DO,... ,D7 
E 

GC 

HD 

IC 

LOC 

LV 

MAX 

N 

NUM 

P 

PC 

0 

RETURN 

SIM 

SP 

SR 


analog-to-dlgital converter 

processor address registers 

COMP processor 

character( s) 

change 

constant 

refers to disable task or use default value for constant or 
variable IC or hold 

simulation data base 

delete 

processor data registers 
refers to enable task 
global constant 
hold value 

initial-condition value 
memory location 
program local variable 
ma x i mum 
no 

number( s) 

PREP processor 

process program counter 

quit 

press RETURN key, <CR> 
simulation, simulator 
processor stack pointer 
processor status register 
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XV 


program external variable 
yes 


Y 

# return to higher prompt or command level 

/ delete Item from argument or general group 

< Insert Item before current Item In argument or general group 

> Insert Item after current Item In argument or general group 


29 



REFERENCES 


1. O'Grady, E. Pearse; and Wang, Chung-Hslen: Multibus-Based Parallel Pro- 

cessor for Simulation. Proceedings of the 1983 Summer Computer Simulation 
Conference, Society for Computer Simulation, 1983, pp. 371-375. 

2. Danlele, Carl J.; and McLaughlin, Peter W.: The Real-Time Performance of 

a Parallel, Nonlinear Simulation Technique Applied to a Turbofan Engine. 
Modeling and Simulation on Microcomputers: 1984, Ray Swartz, ed.. Society 
for Computer Simulation, 1984, pp. 167-171. 

3. Makoul, All; and Karplus, Walter J.: Data Flow Methods for Dynamic System 

Simulation: A CSSL-IV Microcomputer Network Interface. Proceedings of 

the 1983 Summer Computer Simulation Conference, Society for Computer Simu- 
lation, 1983, pp. 376-382. 

4. Collins, W. Robert; and Feyock, Stefan: The Use of ADA In Distributed 

Simulations. Proceedings of the 1983 Summer Computer Simulation Confer- 
ence, Society for Computer Simulation, 1983, pp. 364-370. 

5. Blech, Richard A.; and Arpasl, Dale J.: An Approach to Real-Time Simula- 

tion Using Parallel Processing. NASA TM-81731, 1981. 

6. Blech, Richard A.; and Arpasl, Dale J . : Hardware for a Real-Time Multi- 

processor Simulator. NASA TM-83805, 1984. 

7. Arpasl, Dale J.: RTMPL - A Structured Programming and Documentation 

Utility for Real-Time Multiprocessor Simulations. NASA TM-83606, 1984. 

8. Arpasl, Dale J.: Real-Time Multiprocessor Programming Language (RTMPL): 

Users Manual. NASA TP-2422, 1984. 

9. Cole, Gary L.: Operating System for a Real-Time Multiprocessor Propulsion 

System Simulator. NASA TM-83605, 1984. 

10. Glaser, Jay G.: The VERSAdos Operating System. Microprocessor Operating 

Systems, John Zarrella, ed.. Microcomputer Applications, 1981, pp. 9-1 to 
9-20. 


30 



TABLE I. - OPERATING SYSTEM M AND H ADVISORY MESSAGES 


Number 

Message 

201 

WARNING! MESSAGE STORAGE MEMORY FULL - OVERWRITING OLDEST 

202 

WARNING! DATA STORAGE MEMORY FULL - NO MORE DATA SAVED 

230 

UNDEFINED MODE SELECTED 

231 

HOLD MODE COMPLETED 

232 

SIMULATOR HALT! WATCHDOG TIMEOUT 

233 

SPURIOUS PROGRAMMABLE TIMER INTERRUPT 

234 

SIMULATOR HALT! UPDATE INTERVAL FAILURE 

235 

SAMPLE PROCESS COMPLETE 

236 

ADVISORY LINK OPERATIONAL 

237 

SIMULATOR HALT! RATE OF CHANGE VIOLATION 

238 

SIMULATOR HALT! SPURIOUS INTERRUPT VECTOR 

239 

SIMULATOR HALT! UNINITIALIZED INTERRUPT VECTOR 

240 

SIMULATOR HALT! SYSTEM FAILURE 

241 

SIMULATOR HALT! BUS CLEAR LINE DRIVEN LOW BY BUS ARBITER 

242 

SIMULATOR HALT! SERIAL PORT INTERRUPT 

243 

SIMULATOR HALT! VERSABUS ACFAIL OR BUS RELEASE LINE LOW 

244 

SIMULATOR HALT! VM02 ABORT PUSHBUTTON PRESSED 

245 

SIMULATOR HALT! MISCELLANEOUS 

246 

SIMULATOR HALT! LINE 1111 EMULATOR 

247 

SIMULATOR HALT! LINE 1010 EMULATOR 

248 

SIMULATOR HALT! TRACE 

249 

SIMULATOR HALT! PRIVILEGE VIOLATION 

250 

SIMULATOR HALT! TRAPV INSTRUCTION 

251 

SIMULATOR HALT! CHK INSTRUCTION 

252 

SIMULATOR HALT! ZERO DIVIDE 

253 

SIMULATOR HALT' Tl 1 EGAL INSTRUCTION 

254 

SIMULATOR HALT! ADORESS ERROR 

255 

t 

SIMULATOR HALT! BUS ERROR 
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TABLE II. - SUMMARY OF RTMPOS VERSION 1.0, 090684, MENU SELECTIONS 


[Mode selections may be made in response to any menu prompt.] 


Main menu selection: 

Discussed 
on page 

(S) Stop mode 

11 

(R) Run mode 

1 1 

(H) Hold mode 

11 

(C) Cycle mode 


(1) Initialize simulator hardware 

12 

(2) Display/set update interval and number of ADC channels 

12 

(3) Session history (submenu) 

13 

(1) Display date/time on terminal and in session history 

13 

(2) Enter comment in session history file 

13 

(3) Execute an existing session history file 

13 

(4) Be prompted for file to save session history 

13 

(6) Stop saving session history 

14 

(4) Data-base loading and management (submenu) 

14 

(1) Load simulation data base into (-EP 

14 

(2) Display/edit argument group definitions 

14 

(3) Display/edit values of simulation constants or variable 


1 C /ho 1 d values 

16 

(4) Display/edit general group definitions 

16 

(6) Display/edit user defined advisory messages 

17 

(6) Save current edited data base on disk(ette) 

17 

(/) Get listing of current data base 

17 

(8) Display data base status 

17 

(9) Delete current data base from fEP memory 

17 

(6) Simulation toading/ic and program control (submenu) 

18 

(1) load simulation into simulator 

18 

(?) Set simulation IC's 

18 

(3) Change background executives 

18 

(4) t nable/di sable program tasks 

19 

(f>) Display program status (active executives and enabled tasks) 

19 

(6) Unload simulator 

19 

(6) Simulation results management (submenu) 

19 

(1) Activate/deactivate analysis functions 

19 

(2) Save sample data, display maximum/minimum values 

20 

(3) Display simulator CPU time and simulation time 

20 

(4) Display COMP and PRLP computation times 

21 

(5) Be prompted for file to save simulation results 

21 

(b) List simulation results data file 

21 

(7) Plot simulation results data file 

21 

(8) Display simulation values of constants, variables, and 


argument/general groups 

21 

(9) Display COMP and PRtP advisory maximum delay times 

21 

(10) Display external variable delay times 

22 

(/) Read/write memory location (submenu) 

22 

(1) Display memory location 

22 

(2) Write memory location 

22 

(8) Suspend R1MP0S temporarily 

12 

(9) Quit 

12 
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Figure 1. - General simulator configuration. 
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Figure 2. - NASA Lewis RTMPS experimental hardware. 
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Figure 3. - RTMPL-generated simulation files 
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*::**:* *: * *: tt *: :* xc >k NASA LERC RTMPOS VERSION ? 1 + 0 v 090634 :* xok *::* *: >k w. :* * :* *: * *:**:* 


RTMPOS AUXILIARY & COMP (PROCESSOR MEMORY BEING ATTACHED 
MEMORY SUCCESSFULLY ATTACHED AND AUXILIARY MEMORY CLEARED 

ADVISORY MESSAGE DEVICE XSt #PR OK <Y/N> ? ** Y 

XR> WHEN MESSAGE DEVICE READY , * 

SESSION HISTORY FILE IS ? DEVI ? 0 ♦ SESSHST ♦ SCRATCH ♦ Sl-I OK CY/N) ? , N 

DEFINE FILE TO SAVE SESSION HISTORY I 

ENTER VOLUME NAME <4 CHAR MAX) *♦ DEVI 

ENTER USER NUMBER (4 CHAR MAX) *♦ 0 

ENTER CATALOG NAME <8 CHAR MAX) *♦ SESSHST 

ENTER FILE NAME (8 CHAR MAX) ♦ ♦ T700DUAL 

LOAD DISK < ETTE ) DEVI TO SAVE SESSION HISTORY! THEN HIT RETURN ♦, 

9K3KXMC3K TESTING FOR EXISTENCE OF 5 DEV 1 1 0 « SESSHST , T7 0 ODIJ AL * SH 


SESSION HISTORY FILE SAVED AS? DEVI S 0 .SESSHST . T7-0 0DUAL *SH 


READY TO BEGIN SIMULATION SESSION? 

***# BET SIMULATOR MODI": BY ENTERING 1ST LETTER OF MODI": NAME! 
**** IN RESPONSE: TO ANY MENU SELECTION PROMPT 
<CR> TO CONTINUE * * 


56 

57 

58 

59 

60 
61 
62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 


x)K*;)K»:)K)ioK)»OK^or)K:>K)K)K*:)K)K)K MAIN MENU OF R*T*M*P#0*S FUNCTIONS ****** ** ** ****** **** 

SIMULATOR MODE ? 

*<S) STOP MODE 
<R) RUN MODE 
<H> HOLD MODE 
(C) CYCLE MODE 


OTHER FUNCTIONS ? 

<1) INITIALIZE SIMULATOR HARDWARE 

< 2 ) DISPLAY/SET UPDATE-INTERVAL AND NUMBER OF ADC CHANNELS 

(3) SESSION HISTORY 

(4) DATA BASE LOADING & MANAGEMENT 

C 5 ) SIMULATION LOADING/IC & PROGRAM CONTROL 
(6) SIMULATION RESULTS MANAGEMENT 
<7) READ/WRITE MEMORY LOCATION 
<8) SUSPEND RTMPOS TEMPORARILY 
<9) QUIT 

SELECTION ? . ♦ 


Figure 4 - Terminal display for example simulation session. 
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1 ! SESSION HISTORY FILE ♦ DEVI i 0 ♦ SESSI 1ST * T70 ODUAL ♦ SH 

2 ! DATE % 09/06/BT TIME i 13 M. (HOT ** OF PREVIOUS ! COMMENT ** 

3 
T 

5 1 MAIN MENU SELECTION ♦ ♦ 

6 1 

7 Y 

8 ! CHANNEL. 1 PASSED HARDWARE TEST 

9 ! CHANNEL. 1 READY 

10 ! CHANNEL 1 IS THE RfX 

1 1 

12 ! MAIN MENU SELECTION * ♦ 

13 T 

IT ! SUBMENU SELECTION <■ * 

15 :i. 

16 DEVI 

17 0 

18 SIMDEF 

19 T7 00 DUAL 
2 0 Y 

21 ' DATA BASE HAS BEEN LOADED FOR SIMUL ATION FIL E DEVI 5 0 0 0 0 . SIMDEF * T7 0 ODUAL ♦ DB 

22 1 DATE; 09/06/BT TIME: 13: 12:21 ** OF PREVIOUS ! COMMENT ** 

23 

2T 1 SUBMENU SELECTION ♦ ♦ 

25 T 

26 CROUP 1 

27 1 GENERAL GROUP " GROUP 1 " DOESN'T EXIST! CREATE IT <Y/N) ? *♦ 

28 Y 

29 1 CREATE A NEW GENERAL GROUP i GROUP 1 

30 ! ENTER ITEM TO BE ADDED TO GROUP ♦* 

31. TIME 

32 1 ENTER ITEM TO BE ADDED TO GROUP * , 

33 NP 

3T ! ENTER ITEM TO BE ADDED TO GROUP . . 

35 .P.NG 

36 1 ENTER ITEM TO BE ADDED TO GROUP . . 

37 •li- 
as ! GENERAL GROUP “ GROUP 1 " HAS 3 ITEMS 

39 # 

TO 

Tl 1 SUBMENU SELECTION . , 

T2 

T3 1 MAIN MENU SELECTION * . 

TT 5 

T5 I SUBMENU SELECTION * ♦ 

T 6 1. 

T7 ' T7002CH1 (RTX )i CHANNEL. NO. .. 

TO 1 
T9 Y 

50 DEVI 

51 0 

52 ! CHANNEL- 1 HAS BEEN LOADED WITH PROGRAM " T70 02CH1 *C" 

53 i CHANNEL. 1 HAS BEEN LOADED WITH PROGRAM " T70 02CIT1 .P “ 

5T ! NAME OF SIMULATION INTEGRATION -STEP SIZE PAR AM ... 

55 TIMDEL 

56 ! THE CURRENT INTEGRATION STEP SI/E IS 0.00020 SEC 

57 ' UPDATE INTERVAL. ( MICROSEC)? 50 0 0 

58 ' NUMBER OF ADC CHANNELS t 0 

59 < OK (Y/M) ? .♦ 

6*1 I SIMULATION WILL RUN SLOWER THAN REAL. TIME BY A FACTOR OF 25,0 0 

62 ' ST Ml II ATOP CHANNFI S HAVE BEEN LOADED AND UPDATED FOR THE CURRENT DATA BAbE 

63 * DA T F ; 09/06/8T TIME i 13 1 15 JOT ** OF PREVIOUS » COMMENT ** 

6 q i ' ***** SIMULATION PROGRAM STATUS ***** 

65 < date: 09/ 06/ST TIME J 13 i 15 JOT ** OF PREVIOUS ' COMMENT ** 

66 ! PROGRAM: T7002CH1.C? CHANNELS 1? ACTIVE EXECUTIVE: T700EXE* 

67 1 ENABLED TASKS J NONE AVAIL.. ABLE 

68 ! PROGRAMS T 70 02 CHI * P # CHANNEL.: If ACTIVE EXECUTIVE: T7 0 0EXE ♦ 

69 I ENABLED TASKS: NONE AVAILABLE 

70 Y 

71 ! SIMUI ATION DATA EILEt DEVI J 0 .DATA. SCRATCH ♦ DP 

72 I DATE: 09/06/BT TIME: 13:15:20 ** OF PREVIOUS ! COMMENT ** 

73 ' SIMUI AT OR IN "HOLD - MODE TO INITIALIZE SIMULATION XV * S 

7T I DATE: 09/06/BT TIME: 13:15:20 ** OF PREVIOUS ! COMMENT ** 

75 ! Cl ; PREP ; 0 f SYSTEM ADVISORY MESSAGE NO. 236 

76 !C:l. fCOMP f 0 ? SYSTEM ADVISORY MESSAGE NO, 236 

77 ' SIMULATOR IN “STOP' MODE 

78 

79 1 SUBMENU SELECTION ♦ . 

80 

81. 1 MAIN MENU SELECTION . . 

Figure 5. - Session history tile listing for example session. 
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82 6 

83 ! SUBMENU SELECTION ** 

8<4 1 

85 1 

86 GROUP I 

87 ! TRIGGER SAMPLE ON RUN/HOLD MODE <CR> OR ENTER VARIABLE NAME ♦ * 

88 

89 ! NUMBER OF UPDATES/SAMPLE ♦ * 

90 500 

91 ! NUMBER OP SAMPLES (0 0*1000 SEC/SAMPLE) .* 

92 20 

93 a 

94 

95 ! SUBMENU SELECTION ♦ ♦ 

96 R 

97 ! SIMULATOR IN "RUN" MODE RUN/HOLD NO * 1 

98 ! DATE: 09/06/8^4 TIME: 13: 17: 25 ** OF PREVIOUS ! COMMENT **. 

99 

100 ! SUBMENU SELECTION ** 

101 S 

102 ! Cl ; COMP; 950 o; SYSTEM ADVISORY MESSAGE NO* 235 

103 ! SIMULATOR IN "STOP" MODE 
10 '4 

105 ! SUBMENU SELECTION ♦♦ 

106 2 

107 1 

108 ! 20 RECORDS OP SAMPLE DATA WERE SAVED IN DEVI : 0 ♦ DATA* SCRATCH* DP 

109 Q 

110 

111 ! SUBMENU SELECTION *. 

112 

113 ! MAIN MENU SELECTION *♦ 

11*4 9 

115 ! CURRENT DATA BASE HASN'T BEEN SAVED! SAVE IT BEFORE QUITTING (Y/N) ? ** 

116 Y 

117 Y 

118 ! ***** DATA BASE STATUS ***** 

119 ! DATE: 09/06/8*4 TIME: 13:21 : 19 ** OF PREVIOUS ! COMMENT ** 

120 4 THE FOLLOWING FILES OF " DEVI t 0 0 0 0 ♦ SIliDEF * T7 0 0 DUAL ♦ DB " HAVE BEEN EDITED 

121 ! DEVI : 0 ♦ GGRPDEF ♦ T7 0 0 DUAL ♦ DB AND/OR DEVI : 0 ♦ GLSTDEF * T7 0 0 DUAL « DB 

122 Y 

123 Y 
12'4 Y 

125 Y 

126 Y 

127 ! CURRENT DATA BASE FOR DEVI * 0000 *SIhDEF *T700DUAL*DB BEING SAVED 

128 ! DATE: 09/06/8^4 TIME: 13:22:01 ** OF PREVIOUS ! COMMENT ** 

129 ! GENERAL GROUP RECORD FILE SAVED AS: DEVI : 0 * GGRPDEF . T700DUAL ♦ DB 

130 ! GENERAL GROUP LIST FILE SAVED AS: DEVI : 0 * GLSTDEF *T700DUAL*DB 

131 ! SIMULATION DEFINITION FILE SAVED ASJ DEVI : 0000 *SIMDEf * T7 00 DUAL *DB 

132 

133 ! MAIN MENU SELECTION * * 

13*4 9 


Figure 5. - Concluded. 


DATE: 09/06/84 TIME: 13:10:0*4 

SESSION HISTORY FILE SAVED AS: DEVI: 0 . SESSHST. T700DUAL. SH 

!!!! FROM CHANNEL 01 PREP: 

236 ADVISORY LINK OPERATIONAL 
!!!! FROM CHANNEL 01 COMP: 

236 ADVISORY LINK OPERATIONAL 

DATE: 09/06/84 TIME: 13:15:02 

SIMULATOR IN "RUN” MODE RUN/HOLD NO. 1 
! ! ! ! FROM CHANNEL 01 COMP: 

235 SAMPLE PROCESS COMPLETE 

Figure 6. - Advisory message device display. 
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!L ! GENERAL SESSION HISTORY FILE FOR LOADING SINGLE-CHANNEL* 


n 

! DUAL -PROCESSOR SIMULATION 





5 

! MAIN MENU SELECTION . . L INITIALIZE 

HARDWARE 1 

6 

1 


7 

Y 


f:) 

9 

! MAIN MENU SELECTION ♦ . f! LOAD DATA 

base ::i 

:L 0 

T 


11 

! SUBMENU SELECTION . . 


13 

DEVI 


1^ 

0 


15 

SIMDEF 


16 

T7 00 DUAL 


17 

Y 


18 



19 

! SUBMENU SELECTION ♦ . 


20 



21 

! MAIN MENU SELECTION . . t" LOAD SIMUALTION !] 

23 

! SUBMENU SELECTION . ♦ 


2T 

1 


25 

! T7002CH1 ( RTX >: CHANNEL NO* ♦♦ 

C CHANNEL 1 ASSUMED TO BE 

26 

1 


27 

Y 


28 

DEVI 


29 

0 


30 

! NAME OF SIMULATION INTEGRATION- STEP- 

SIZE PAR AM * * 

31 

TIMDEL 


32 

! THE CURRENT INTEGRATION STEP SIZE I£ 

0.00020 SEC 

33 

\ UPDATE INTERVAL (MICROSEC ) t 5000 


3T 

! NUMBER OF ADC CHANNELS t 0 


35 

! OK (Y/N) ? . . 


36 

Y 


37 

! SIMULATION DATA FILE WILL. BE DEFAULT 

FILE : DEVI : 0 . DATA . SCRATCH 

33 

Y 


39 



TO 

\ SUBMENU SELECTION * * 



Figure 7. - General session history file for initializing simulator hardware and loading a single-channel, 
dual-processor simulation. 
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